Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(releases): adding correct confirmation dialog to archive release flow #7827

Merged
merged 6 commits into from
Nov 18, 2024

Conversation

jordanl17
Copy link
Member

@jordanl17 jordanl17 commented Nov 18, 2024

Description

The current flow for archiving, although correctly using the server action, was not implementing the correct UX.
Now, archiving brings up the correct confirmation dialog.
Unarchiving has also been no-op-ed as the action doesn't exist right now
Screenshot 2024-11-18 at 10 58 27

What to review

Specifically, looking for thoughts on:

Interested to know thoughts both on directory structure for these mocks and fixtures, and the naming convention for these files also. Further thoughts:

  1. Separating mocks (eg vi.mock usage for export mocks) and fixtures (objects and other primitives that can be used consistently across all our tests)
  2. mocks sit alongside the files they are mocking the shape of; fixtures sit inside the domain space they are related to
  3. mocks can still be overridden on test by test to customise
  4. fixtures are explicit and exact - they can be spread as necessary, but don't implement factory or builder patterns choosing to just plain JS objects instead

Testing

Note testing thoughts above

Notes for release

N/A

Copy link

vercel bot commented Nov 18, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
page-building-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 4:29pm
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 4:29pm
test-compiled-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 4:29pm
test-next-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 4:29pm
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 18, 2024 4:29pm
1 Skipped Deployment
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Visit Preview Nov 18, 2024 4:29pm

Copy link
Contributor

No changes to documentation

Copy link
Contributor

github-actions bot commented Nov 18, 2024

Component Testing Report Updated Nov 18, 2024 4:28 PM (UTC)

✅ All Tests Passed -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 1m 10s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 13s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ✅ Passed (Inspect) 40s 6 0 0
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 55s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 26s 6 0 0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx ✅ Passed (Inspect) 16s 3 0 0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx ✅ Passed (Inspect) 2m 33s 1 0 0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx ✅ Passed (Inspect) 1m 10s 15 0 0
formBuilder/inputs/PortableText/Input.spec.tsx ✅ Passed (Inspect) 2m 39s 21 0 0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx ✅ Passed (Inspect) 1m 45s 18 0 0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx ✅ Passed (Inspect) 13s 3 9 0
formBuilder/inputs/PortableText/RangeDecoration.spec.tsx ✅ Passed (Inspect) 40s 9 0 0
formBuilder/inputs/PortableText/Styles.spec.tsx ✅ Passed (Inspect) 28s 6 0 0
formBuilder/inputs/PortableText/Toolbar.spec.tsx ✅ Passed (Inspect) 55s 12 0 0
formBuilder/tree-editing/TreeEditing.spec.tsx ✅ Passed (Inspect) 0s 0 3 0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx ✅ Passed (Inspect) 0s 0 3 0

Copy link
Contributor

github-actions bot commented Nov 18, 2024

⚡️ Editor Performance Report

Updated Mon, 18 Nov 2024 16:29:53 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 17.5 efps (57ms) 12.6 efps (80ms) +23ms (+39.5%) 🔴
article (body) 56.2 efps (18ms) 56.7 efps (18ms) -0ms (-0.8%)
article (string inside object) 17.9 efps (56ms) 13.5 efps (74ms) +18ms (+32.1%) 🔴
article (string inside array) 15.9 efps (63ms) 11.4 efps (88ms) +25ms (+39.7%) 🔴
recipe (name) 32.3 efps (31ms) 20.4 efps (49ms) +18ms (+58.1%) 🔴
recipe (description) 35.7 efps (28ms) 21.3 efps (47ms) +19ms (+67.9%) 🔴
recipe (instructions) 99.9+ efps (6ms) 99.9+ efps (6ms) +0ms (-/-%)
synthetic (title) 13.7 efps (73ms) 5.8 efps (174ms) +101ms (+137.7%) 🔴
synthetic (string inside object) 14.5 efps (69ms) 5.9 efps (169ms) +100ms (+144.2%) 🔴

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 57ms 60ms 65ms 231ms 449ms 13.3s
article (body) 18ms 21ms 25ms 251ms 457ms 6.1s
article (string inside object) 56ms 60ms 70ms 216ms 480ms 8.9s
article (string inside array) 63ms 68ms 75ms 160ms 879ms 9.5s
recipe (name) 31ms 33ms 37ms 65ms 12ms 8.3s
recipe (description) 28ms 30ms 32ms 44ms 0ms 5.7s
recipe (instructions) 6ms 8ms 8ms 10ms 0ms 3.1s
synthetic (title) 73ms 75ms 82ms 158ms 1186ms 15.4s
synthetic (string inside object) 69ms 72ms 86ms 550ms 2188ms 11.0s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 80ms 85ms 105ms 357ms 3052ms 17.0s
article (body) 18ms 23ms 40ms 275ms 528ms 6.1s
article (string inside object) 74ms 78ms 84ms 423ms 2470ms 11.5s
article (string inside array) 88ms 92ms 96ms 484ms 3339ms 12.2s
recipe (name) 49ms 52ms 71ms 124ms 879ms 10.6s
recipe (description) 47ms 49ms 58ms 165ms 730ms 8.1s
recipe (instructions) 6ms 8ms 8ms 19ms 0ms 3.2s
synthetic (title) 174ms 184ms 225ms 842ms 10716ms 27.7s
synthetic (string inside object) 169ms 177ms 187ms 859ms 9343ms 20.5s

📚 Glossary

column definitions

  • benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
  • latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
  • p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
  • p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
  • p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
  • blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
  • test duration — how long the test run took to complete.

@@ -0,0 +1,17 @@
import {type ReleaseDocument} from '../store/types'

export const activeScheduledRelease: ReleaseDocument = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking that we'd continue to create others here eg activeASAPRelease as are necessary for test cases across our suite. All fixtures would be correct and valid states, eg activeASAPRelease would not have an intendedPublishAt since that is not a valid state machine value

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😚 👌

vi.mock('sanity', () => ({
SANITY_VERSION: '0.0.0',
useTranslation: vi.fn().mockReturnValue({t: vi.fn()}),
vi.mock('../../../../store/useReleaseOperations', () => ({
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried in vain to simplify the way this could be mocked, but a mixture of issues an nuance with how vi.mock is hoisted and executed mean we still need these mock statements explicitly in our tests rather than in generalised mock files

@jordanl17 jordanl17 marked this pull request as ready for review November 18, 2024 11:09
@jordanl17 jordanl17 requested a review from a team as a code owner November 18, 2024 11:09
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice nice nice nice

Copy link
Contributor

@RitaDias RitaDias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rogue thought I had when I was reviewing this related to where wea re placing the fixtures.
I think it might make better sense to keep them somewhere along like we do with the TestProvider in the test directory?

Right now we are keeping in the core/releases but I feel it will come a point where we might want to use releases in other places for one reason or another. Especially since this does kinda touch more parts than this self contained part (the first thing that comes to mind right now are some components in structure).

I'm not married to the idea but I think findability might be better :)

</Text>
),
})
console.error(archivingError)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rogue console log or meant to be here? :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed similar approach to what we do in Publish and schedule, so this is intended

@@ -67,6 +150,8 @@ export const ReleaseMenuButton = ({disabled, release}: ReleaseMenuButtonProps) =
{!release?.state || release.state === 'archived' ? (
<MenuItem
onClick={handleUnarchive}
// TODO: disabled as CL action not yet impl
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a linear story for this? 👀

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we do corel-256

Copy link
Contributor

@RitaDias RitaDias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few comments and a suggestion, great job :)

telemetry.log(UnarchivedRelease)
setIsPerformingOperation(false)
// noop
// TODO: similar to handleArchive - complete once server action exists
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the reason for deleting this? Do we expect unarchive to change significantly?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will change from what it currently is in corel (will be updated to to be similar to archive). I considered implementing it, but feel it's better to complete the full task once the action can be test alongside. There's a separate task I'm monitoring and will complete once ready


import {type ReleaseOperationsStore} from '../../createReleaseOperationStore'

export const useReleaseOperationsMock: Mocked<ReleaseOperationsStore> = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a great pattern to me!

Copy link
Member

@bjoerge bjoerge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@jordanl17 jordanl17 merged commit 474bfba into corel Nov 18, 2024
56 of 58 checks passed
@jordanl17 jordanl17 deleted the corel-255-archive-confirmation branch November 18, 2024 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants